Компания ИТ-ГРАД, ведущий российский провайдер IaaS-инфраструктур на базе VMware vSphere, предлагает нашим читателям бесплатную книгу "IaaS для бизнеса по кирпичикам" об аренде виртуальных машин из облака.

Книга предназначена для тех, кто впервые сталкивается с облаками и понятием IaaS (Infrastructure as a Service).

Книга рассчитана на бизнес-аудиторию, желающую разобраться в последних тенденциях в сфере ИТ.

Книга написана доступным языком, позволяет за 5 минут погрузиться в базовые определения и принципы построения эффективной ИТ-инфраструктуры.

Прочитав данную книгу, вы найдете ответы на следующие вопросы:

• Какие ИТ-сервисы имеет смысл выносить на аутсорсинг?
• Какие сервисы лучше оставить внутри?
• 7 шагов по снижению рисков перехода в облако.
• Как выбрать поставщика облачных услуг и убедиться в его надежности?

Ссылка на скачивание книги придет вам на электронную почту после заполнения формы.

Как установить IP-параметры HP iLO через консоль сервера VMware ESXi.

При развертывании инфраструктуры VMware vSphere на базе серверов HP всегда требуется задать параметры IP-идентификации для интерфейса удаленной консоли iLO. Обычно это делается в настройках сервера, но удобнее сделать это из консоли ESXi, если вы используете кастомизированную сборку ESXi под HP (а ее надо использовать, так как некоторые девайсы могут просто не работать, поскольку в стандартной сборке под них нет драйверов).

Для начала откроем на хосте ESXi доступ по SSH в разделе Security Profile, стартовав соответствующий сервис:

Заходим на хост по SSH и переходим в папку с утилитами HP:

cd /opt/hp/tools

Копируем настройки HP iLO в файл XML:

./hponcfg -w ilo.xml

Далее этот файл нам нужно отредактировать, для этого можно использовать WinSCP или Veeam FastSCP.

Копируем iLO.xml к себе локально:

Открываем его в текстовом редакторе и правим секции, помеченные красным:

<!-- HPONCFG VERSION = "4.0-13.0" -->
<!-- Generated 11/11/2014 23:37:47 -->
<RIBCL VERSION="2.1">
<LOGIN USER_LOGIN="Administrator" PASSWORD="password">
<DIR_INFO MODE="write">
<MOD_DIR_CONFIG>
<DIR_AUTHENTICATION_ENABLED VALUE = "N"/>
<DIR_LOCAL_USER_ACCT VALUE = "Y"/>
<DIR_SERVER_ADDRESS VALUE = ""/>
<DIR_SERVER_PORT VALUE = "636"/>
<DIR_OBJECT_DN VALUE = ""/>
<DIR_OBJECT_PASSWORD VALUE = ""/>
<DIR_USER_CONTEXT_1 VALUE = ""/>
<DIR_USER_CONTEXT_2 VALUE = ""/>
<DIR_USER_CONTEXT_3 VALUE = ""/>
</MOD_DIR_CONFIG>
</DIR_INFO>
<RIB_INFO MODE="write">
<MOD_NETWORK_SETTINGS>
<SPEED_AUTOSELECT VALUE = "Y"/>
<NIC_SPEED VALUE = "100"/>
<FULL_DUPLEX VALUE = "N"/>
<IP_ADDRESS VALUE = "192.168.16.33"/>
<SUBNET_MASK VALUE = "255.255.255.0"/>
<GATEWAY_IP_ADDRESS VALUE = "192.168.16.254"/>
<DNS_NAME VALUE = "ESX01-iLO"/>
<PRIM_DNS_SERVER value = "192.168.16.1"/>
<DHCP_ENABLE VALUE = "N"/>
<DOMAIN_NAME VALUE = "educ.local"/>
<DHCP_GATEWAY VALUE = "Y"/>
<DHCP_DNS_SERVER VALUE = "Y"/>
<DHCP_STATIC_ROUTE VALUE = "Y"/>
<DHCP_WINS_SERVER VALUE = "Y"/>
<REG_WINS_SERVER VALUE = "Y"/>
<PRIM_WINS_SERVER value = "0.0.0.0"/>
<STATIC_ROUTE_1 DEST = "0.0.0.0" GATEWAY = "0.0.0.0"/>
<STATIC_ROUTE_2 DEST = "0.0.0.0" GATEWAY = "0.0.0.0"/>
<STATIC_ROUTE_3 DEST = "0.0.0.0" GATEWAY = "0.0.0.0"/>
</MOD_NETWORK_SETTINGS>
</RIB_INFO>
<USER_INFO MODE="write">
</USER_INFO>
</LOGIN>
</RIBCL>

Копируем измененный файл обратно на хост ESXi (предыдущий сохраните - просто переименуйте) и выполняем команду заливки конфигурации:

./hponcfg -f ILO.xml

Дождитесь успешного выполнения команды - и можно коннектиться к iLO через веб-браузер по новому адресу. Этот способ удобен тем, что можно не перезагружать сервер.

Многие пользователи VMware Virtual SAN (VSAN), когда проводят тест бэкапа одной виртуальной машины, замечают, что время резервного копирования этой ВМ существенно больше, чем таковое для машины, размещенной на дисковом массиве.

Дункан в своем блоге подробно разбирает эту проблему. Тут дело вот в чем - когда вы используете дисковый массив, то виртуальная машина "размазывается" по дискам RAID-группы, что позволяет читать одновременно с нескольких дисков. Это дает хорошую производительность операции резервного копирования для одной машины.

Кластер же VSAN работает немного по-другому. Это объектное хранилище, в котором виртуальный диск ВМ хранится на одном хосте и его реплика существует на втором. Кроме этого, есть кэш на SSD-диске (но его еще нужно "прогреть"). То есть выглядит все это следующим образом:

Соответственно, при бэкапе одной виртуальной машины данные читаются только с двух HDD-дисков, а не с нескольких как в традиционной архитектуре дисковых массивов, при этом сам кластер VSAN может состоять из нескольких хостов (до 32 узлов). То есть, это архитектурное ограничение.

Однако если мы будем делать одновременный бэкап нескольких виртуальных машин с хранилища Virtual SAN время этой операции уже будет сравнимо с дисковым массивом, поскольку будет задействовано сразу несколько дисков на каждом из хостов, плюс хорошо прогреется кэш. Поэтому проведение такого теста (ведь он ближе к реальным условиям) и было бы более показательным при сравнении Virtual SAN и традиционных хранилищ.

То же самое относится и к VDI-инфраструктуре на базе VSAN - многие пользователи отмечают, что первая фаза операции Recompose (когда создается реплика - полный клон ВМ) отрабатывает весьма медленно. Однако если вы делаете много таких операций - кэш прогревается, и одновременное создание нескольких клонов начинает работать заметно быстрее в расчете на одну машину.

Мы довольно часто пишем про продукт номер 1 для защиты виртуальных инфраструктур VMware и Microsoft - vGate R2. Напомним, что недавно мы рассказали о настройке решения vGate R2 для Hyper-V, которое вышло несколько месяцев назад, но уже обладает очень мощным функционалом.

Кроме того, не стоит забывать и о версии vGate R2 для защиты виртуальных инфраструктур на платформе VMware vSphere, которая выпускается уже много лет и была доступна еще для VMware ESX 3.x.

С тех пор очень многое изменилось, продукт используется во множестве крупных российских компаний для обеспечения защиты от несанкционированного доступа, а также приведения инфраструктуры в соответствие отраслевым стандартам и лучшим практикам средствами политик.

Поэтому для вашего удобства компания Код Безопасности сделала табличку со списком измнений vGate от версии к версии (информация актуальна для коммерческих релизов).

Например в vGate R2 релиз 2.7 появились следующие новые возможности:

• Обеспечена поддержка работы vSphere 5.5 Web-client.
• Добавлен шаблон настроек для нового стандарта VMware Security Hardening Guide 5.5.
• Обеспечена поддержка сценария развертывания сервера авторизации в виртуальной машине.
• Добавлены новые возможности в консоль управления, обеспечивающие:
  - древовидное отображение списка виртуальных машин;
  - более удобную настройку правил доступа;
  - оптимизацию работы за счет возможности отключения контроля уровня сессий пользователей;
  - установку компонента защиты vCenter из консоли управления vGate

Скачать пробную версию vGate R2 можно по этой ссылке, а за информацией о продукте заходите сюда. Продукт также можно купить онлайн здесь.

Многие пользователи в целях безопасности хотят отключить использование USB-портов на хостах VMware ESXi - а то кто-нибудь зайдет в серверную комнату и утащит данные на диске.

К сожалению, на текущих версиях платформы VMware vSphere сделать этого нельзя. Можно, конечно, отключить USB Arbitrator service следующей командой (как написано вот тут):

/etc/init.d/usbarbitrator stop

Но это лишь отключит проброс USB-устройств в виртуальные машины, при этом само устройство (например,  /dev/usb0101) отключено не будет. Поэтому, тут остается два решения:

• Отключить USB-устройства в BIOS - но это поддерживают не все производители железа.
• Мониторить использование локальных USB-устройств и слать алерты менеджеру по ИБ.

Второй вариант можно реализовать с помощью продукта VMware vRealize Log Insight, который позволяет мониторить логи хостов ESXi и слать по ним алерты при их появлении и повторении. Вот, например, в выводе этого лога мы видим, что кто-то подключал USB-девайс к хосту:

Сопоставив время этих событий и время посещения конкретными людьми датацентра, мы поймем, кто пытался или сделал что-то нехорошее. Решение, конечно, не ахти, но какое уж есть.

На сайте компании VMware есть полезная утилита vSphere Replication Calculator, которая позволяет рассчитать целевые параметры репликации в зависимости от следующих факторов:

• Наличие у вас Network-based storage
• Число виртуальных машин и объем виртуальных дисков - как следствие размер реплицируемых данных (Size of dataset)
• Интенсивность изменения данных (Data change rate)
• Требования к контрольной точке восстановления (Recovery point objective, RPO)
• Имеющийся канал на резервную площадку (Link speed)

В качестве результата расчетов можно выбрать одно из трех представлений (все зависит от значения поля "Are you trying to solve..."):

• Необходимая минимальная пропускная способность сети на резервную площадку (recommended minimum throughput) с приемлемой latency (настраивается как входной параметр).
• Рекомендуемое минимальное время RPO в качестве политики, выражающей требования к контрольной точке восстановления.
• Максимальное число реплицируемых виртуальных машин при условии заданного объема изменяющихся данных.

Получившийся отчет можно сохранить в PDF.

Бывают такие ситуации, когда у вас в руках только мобильный телефон, с которого возникает необходимость перезагрузить виртуальную машину на хосте VMware ESXi. Например, у вас в инфраструктуре что-то случилось, но вы имеете доступ к ней через VPN со своего айфона.

Если у вас есть доступ по SSH, то проблему решить весьма просто, как это описано вот тут (а также в KB 1014165). Скачиваем бесплатное приложение Server Auditor по этой ссылке (если у вас андроид - то по этой).

Далее заходим на свой хост ESXi по SSH и выполняем команду:

esxcli vm process list

Будет выведен список всех процессов виртуальных машин, где нам нужно найти World ID нужной машины. Записываем или запоминаем его.

Далее убиваем виртуальную машину командой (вместо параметра force можно использовать hard и soft для выключения ВМ):

esxcli vm process kill -t force -w WorldID

Выглядит это примерно вот так:

Далее снова выполняем команду esxcli vm process list, чтобы убедиться, что виртуальная машина теперь выключена.

Теперь запоминаем VMID нашей виртуальной машины, который можно получить с помощью команды:

vim-cmd vmsvc/getallvms

Если помните часть имени ВМ, можно искать с помощью grep:

vim-cmd vmsvc/getallvms |grep <текст в имени ВМ>

Найдя VMID, проверяем дополнительно, что она выключена:

vim-cmd vmsvc/power.getstate <vmid>

Теперь включаем виртуальную машину:

vim-cmd vmsvc/power.on <vmid>

Вот и все, потом обязательно нужно проверить, что машина включилась, естественно - сначала в списке процессов, а потом пингом.

Как стало известно из VMware KB 2090639, в гипервизоре VMware vSphere 4.x и всех более поздних версий (включая vSphere 5.5) есть серьезный баг - оказывается, при увеличении виртуальных дисков машин с включенной технологией Changed Block Tracking (CBT), если их результирующий размер перешагивает 128 ГБ (а также 256, 512, 1024 и т.д.) - их резервные копии оказываются невалидными и не подлежащими восстановлению.

Напомним, что Changed Block Tracking - это техника, которая работает на уровне стека работы с хранилищами в модуле VMkernel и позволяет сторонним продуктам для резервного копирования вернуть список изменившихся блоков с момента последнего бэкапа. Технику CBT используют практически все решения для резервного копирования виртуальных машин, в частности Veeam Backup and Replication.

Сама же ошибка в VMware vSphere связана с тем, что функция QueryChangedDiskAreas, возвращающая информацию об изменившихся дисковых секторах, может выдавать некорректное или вообще пустое значение. Таким образом, если вы восстановите инкрементальный бэкап такой машины, то он работать не будет.

Еще раз отметим, что риску подвержены только те виртуальные машины, размер виртуальных дисков был увеличен до величины строго большей 128 ГБ (а также 256, 512 и т.п. - то есть "перешагнул" границу). Иными словами, если вы со 100 ГБ увеличили диск до 120 ГБ - ошибки не будет, а вот если со 120 ГБ до 130 ГБ - ошибка уже появится.

На данный момент исправления для этой проблемы, потенциально затрагивающей практически всех пользователей VMware vSphere (так как баг есть и в 4.x, и в 5.x), не существует. В качестве костыля можно отключить CBT на всех виртуальных машинах и включить его снова - тогда баг должен уйти.

Сделать это можно через скрипт PowerCLI.

Получаем список всех виртуальных машин с включенной CBT:

$vms=get-vm | ?{$_.ExtensionData.Config.ChangeTrackingEnabled -eq $true}

Создаем спецификацию для наложения нужной настройки (CBT - отключена):

$spec = New-Object VMware.Vim.VirtualMachineConfigSpec
$spec.ChangeTrackingEnabled = $false

Применяем спецификацию к каждой виртуальной машине, затем создаем и удаляем снапшот:

foreach($vm in $vms){
$vm.ExtensionData.ReconfigVM($spec)
$snap=$vm | New-Snapshot -Name 'Disable CBT'
$snap | Remove-Snapshot -confirm:$false}

Проверяем, остались ли машины со включенной CBT:

get-vm | ?{$_.ExtensionData.Config.ChangeTrackingEnabled -eq $true}

Для того, чтобы включить CBT обратно, в спецификации указываем $spec.ChangeTrackingEnabled = $true и повторяем процедуру.

Как всегда, первой подсуетилась компания Veeam и главный по продукту - Антон Гостев.

Как убедиться в том, что инфраструктура облачного провайдера действительно не имеет единой точки отказа? Проверить это на деле!

В этой заметке сотрудники ИТ-ГРАД расскажут о том, как они проводили приёмо-сдаточные испытания своей новой облачной площадки.

Предыстория

24 сентября мы открыли новую публичную облачную площадку в Санкт-Петербурге. Вот тут предварительный план испытаний облачной платформы.

И вот мы приступаем…

Удаленное тестирование

1. Поочередное выключение контроллеров FAS8040

Ожидаемый результат... [Читать статью далее]

Компания StarWind, поставщик ПО номер 1 для создания отказоустойчивых кластеров хранилищ в инфраструктурах VMware vSphere и Microsoft Hyper-V (о возможностях продукта - тут), спешит анонсировать свои ноябрьские вебинары.

Занесите даты себе в календарь:

6 ноября в 17-00 по московскому времени

Бесплатный вебинар "How to Reduce Disaster Recovery Expenses up to 50% - DR & BC Best Practices for Virtual Environments".

На вебинаре будут рассмотрены следующие темы:

• Бизнес-потребности в решениях для непрерывности бизнеса и восстановления после сбоев (BC/DR).
• Чем решения BC/DR отличаются от простой аппаратной отказоустойчивости.
• Стратегии для внедрения BC/DR на основе вида приложения и целевого уровня сервиса (Service Level Objectives).
• Выбор между решениями для восстановления средствами дискового массива и средствами гипервизора.
• Выбор между решениями для восстановления на уровне ВМ и на уровне LUN.
• Технические решения для отказоустойчивости виртуальных серверов, включая Microsoft Hyper-V, VMware vSphere и платформы с открытым исходным кодом.
• Сторонние решения для восстановления виртуальных сред.

РЕГИСТРАЦИЯ

Бесплатный вебинар "Building a Highly Available Hyper-V Cluster Using Free Microsoft Hyper-V Server"

На вебинаре будут рассмотрены следующие темы:

• Достоинства кластера высокой доступности Hyper-V failover cluster
• Упрощение управления кластером и виртуальными машинами средствами 5nine Manager for Hyper-V
• Сокращение затрат, увеличение надежности и минимизация оборудования за счет StarWind Virtual SAN
• Удовлетворение потребностей виртуальной среды за счет расширения и масштабирования решения

РЕГИСТРАЦИЯ

16 ноября в 23-00 по московскому времени

Бесплатный вебинар "Reduce Disaster Recovery & Business Continuity Expenses with Windows Server Clustering and Geo-Clustering"

На вебинаре будут рассмотрены следующие темы:

• Требования технологии Windows Failover Clustering.
• Рекомендации по кворумным дискам, сетевому окружению и хранилищам.
• Геокластеризация для восстановления после сбоев.
• Использование StarWind Virtual SAN для многоузловых и просто масштабируемых кластеров

РЕГИСТРАЦИЯ

Некоторое время назад мы писали про средство управления инстансами в облаке Amazon для платформы VMware vSphere - AWS Management Portal for vCenter, которое позволяет управлять виртуальными машинами, находящимися в облаке EC2 прямо из консоли vCenter, при этом доступен достаточно обширный набор возможностей.

На днях похожее (только намного более куцее) средство Amazon выпустила и для инфраструктур на базе ПО Microsoft - AWS Systems Manager for Microsoft System Center Virtual Machine Manager.

Данное средство от Amazon позволяет отслеживать список инстансов в облаке EC2 (по регионам и зонам доступности), проводить с ними опреации start/stop/reset и соединяться с консолью нужного инстанса по RDP.

Плагин AWS Systems Manager для SC VMM доступен совершенно бесплатно. Его можно использовать для Microsoft SC VMM 2012 SP1 и более поздних версий. Скачать плагин можно по этой ссылке.

Кстати, кроме этого плагина к SC VMM компания Amazon также предоставляет Management Pack для использования в System Center Operations Manager (для версий 2007 R2 и 2012/2012 R2). Отличия его от вышеупомянутого средства в том, что Management Pack для Operations Manager используется для мониторинга и репортинга по окружению EC2 (в том числе, о производительности), а Systems Manager для SC VMM предназначен, в первую очередь, для операций с виртуальными машинами (запуск/останов/доступ к консоли).

Любители постеров уже давненько не видели чего-то нового от VMware. Но вот очередной постер прибыл - VMware vSphere PowerCLI 5.8 Release 1 Reference Poster. Там, как всегда, вы найдете список командлетов и примеры их применения с учетом последней версии интерфейса к PowerShell - PowerCLI 5.8 Release 1.

Некоторое время назад мы писали о технологии VMware vFlash (она же Virtual Flash), которая позволяет использовать высокопроизводительные накопители SSD (вот тут - о производительности) для решения двух важных задач:

• Предоставление виртуальным машинам дополнительного места, в которое будут свопиться страницы памяти в случае недостатка ресурсов на хосте (это намного более производительно, чем свопить на обычный HDD-диск). Эта техника называется Virtual Flash Host Swap и пришла на смену механизму Swap to SSD.
• Прозрачное встраивание в поток ввода-вывода на хосте между виртуальными машинами и хранилищами, что позволяет существенно ускорить операции чтения данных виртуальных дисков. Называется это VMware Flash Read Cache (vFRC).

Ниже мы вкратце расскажем о настройке этих двух механизмов через VMware vSphere Web Client (в обычном C#-клиенте этого, к сожалению, нет). Если что, более подробно о технике vFRC можно почитать по этой ссылке.

Итак, в vSphere Web Client переходим на вкладку "Manage" для нужного хоста, далее в разделе "Settings" выбираем пункт "Virtual Flash Resource Management". Это кэш, который мы добавляем для того, чтобы в случае нехватки места, его могли использовать виртуальные машины, чтобы не свопить данные на медленный магнитный диск, кроме того он же будет использоваться для целей vFRC.

Нажимаем Add Capacity:

Выбираем диски, которые мы будем использовать как Host Swap и нажимаем "Ок" (все данные на них будут стерты):

Всего под нужды Virtual Flash может быть выделено до 8 дисков суммарной емкостью до 32 ТБ. Видим, что ресурс добавлен как Virtual Flash Resource (его емкость отдельно учитывается для vFRC и Host Cache):

Настройка Virtual Flash Host Swap

Первым делом рекомендуется настроить именно этот кэш, а остаток уже распределять по виртуальным машинам для vFRC.

Выбираем пункт "Virtual Flash Host Swap Cache Configuration" в левом меню, а далее в правой части мы нажимаем кнопку "Edit":

Указываем необходимый объем, который планируется использовать, и нажимаем "Ок":

После того, как мы настроили нужное значение - в случае недостатка ресурсов на хосте виртуальные машины будут использовать высокоскоростные диски SDD для своих нужд внутри гостевой ОС (файлы подкачки прочее).

Настройка VMware Flash Read Cache (vFRC)

Напомним, что это кэш только на чтение данных, операции записи будут производиться на диск, минуя флэш-накопители. Соответственно, такой кэш улучшает производительность только операций чтения.

Сам кэш vFRC можно настроить на уровне отдельных виртуальных машин на хосте VMware ESXi, а также на уровне отдельных виртуальных дисков VMDK.

Чтобы выставить использование нужного объема vFRC для отдельной виртуальной машины, нужно выбрать пункт "Edit Settings" из контекстного меню ВМ и на вкладке "Virtual Hardware" в разделе "Virtual Flash Read Cache" установить нужное значение для соответствующего виртуального диска:

Если этого пункта у вас нет, то значит у вас версия виртуального "железа" (Virtual Machine Hardware) ниже, чем 10, и ее нужно обновить.

По ссылке "Advanced" можно настроить размер блока для кэша (значение Reservation, установленное тут, обновит значение на предыдущем скрине):

Чтобы понять, какие значения SSD-кэша можно и нужно выставлять для виртуальных машин, рекомендуется почитать документ "Performance of vSphere Flash Read Cache in VMware vSphere 5.5".

30 октября компания Код Безопасности проводит бесплатный вебинар "Виртуализация: доступ к данным под контролем", посвященный особенностям защиты виртуальных инфраструктур в соответствии с требованиями регуляторов и новым возможностям продукта vGate R2. Вебинар проведет Яков Хамаганов, эксперт по технологиям защиты информации компании "Код Безопасности".

Вебинар пройдет 30 октября 11-00 по московскому времени. Продолжительность вебинара - 60 минут.

Напомним, что vGate R2 предназначен для защиты виртуальных инфраструктур средствами политик, а также от несанкционированного доступа к элементам инфраструктуры, таким как виртуальные машины, хранилища и сети.

В ходе вебинара Вы узнаете:

• об особенностях защиты информации в виртуальных инфраструктурах VMware vSphere и Microsoft Hyper-V;
• о том, что нового появилось в СЗИ vGate и как с помощью vGate построить надежную систему защиты;
• о том, как сертифицированный vGate поможет выполнить требования приказов №17 и №21 ФСТЭК России по защите персональных данных.

Вебинар будет интересен руководителям служб безопасности и ИТ-директорам, а также специалистам, обеспечивающим безопасность дата-центров и защиту виртуальных инфраструктур.

По окончании вебинара Вы сможете задать докладчику вопросы в режиме чата и оставить заявки на получение демо-версии продукта и дополнительных материалов.

РЕГИСТРАЦИЯ.

Ниже приведем ссылки на статьи VMware Knowledge Base (взято отсюда), где можно узнать о расположении и назначении файлов журнала (логов) для различных продуктов, включая компоненты решения VMware vSphere.

vSphere Suite

vCenter Server:

• Location of vCenter Server log files (1021804)
• Location of vCenter Inventory Service log files (2056632)
• Location of vSphere Profile-Driven Storage log files (2056646)
• Location of vCenter Single Sign-On log files for vCenter Server 5.1 and 5.5 (2033430)
• Collecting diagnostic information for the vSphere Client or VMware Infrastructure Client (1003687)
• Location of vSphere Web Client service logs (2004090)
• Locating logs for VMware vSphere Update Manager 5.0 (2038036)
  

ESX(i):

• Location of vSphere ESXi Dump Collector log files (2003277)
• Location of ESX 3.0-4.1 log files (1021800)
• Location of ESXi 3.5-4.1 log files (1021801)
• Location of ESXi 5.0 log files (2004201)
• Location of ESXi 5.1 and 5.5 log files (2032076)

vSphere Data Recovery:

• Location of VMware Data Recovery (VDR) log files (1022680)

vSphere Storage Appliance:

• Location of vSphere Storage Appliance log files (2003547)

Site Recovery Manager

• Location of Site Recovery Manager log files (1021802)

vCloud Suite

vCloud Director:

• Location of vCloud Director log files (2021435)
• Overview of Lab Manager log files (1011478)

vShield/vCloud Networking and Security (vCNS):

• Overview of vShield logs (1026255)
• Obtaining logs and information needed for VMware vShield products (2012760)

VMware vCloud Automation Center 6.x:

• Log locations in VMware vCloud 6.x Suite (2074803)

vCenter Orchestrator:

• Location of vCenter Orchestrator log files (1010956)

Desktop Computing

View and Horizon View:

• Location of VMware View log files (1027744)

Horizon Mirage (formerly Mirage):

• Location of VMware Horizon Mirage log files (2046069)

VMware Workstation:

• Collecting diagnostic information for VMware Workstation (1346)

Те из вас, кто следит за анонсами VMware VMworld 2014, которые были сделаны в Штатах, а затем в Европе, наверняка слышали о такой штуке как VMware Project Fargo (его прежнее название - VM Fork), которая позволяет очень быстро сделать работающую копию работающей виртуальной машины на платформе VMware vSphere.

Суть технологии VMFork такова, что "на лету" создается клон виртуальной машины (VMX-файл, процесс в памяти), который начинает использовать ту же память (Shared memory), что и родительская ВМ. При этом дочерняя ВМ в шаренную память писать не может, а для записи собственных данных используется выделенная область памяти. Для дисков аналогично - с использованием технологии Copy-on-write в дельта-диск дочерней ВМ пишутся отличия от базового диска родительской ВМ:

Обратите внимание, что дочерняя ВМ появляется на свет без изначальной загрузки.

В процессе работы VMFork происходит кратковременное "подвешивание" родительской ВМ (quiescence) с помощью технологии "fast suspend resume" (FSR), после чего дочерняя ВМ "отцепляется" от родительской. При этом ВМ шарят общие ресурсы на чтение и имеют свои уникальные области на запись - это очень удешевляет стоимость ресурсов в перерасчете на одну ВМ на хосте.

Все это позволяет создать так называемый Just-in-time desktop, который создается до 30 раз быстрее, чем обычный, и "отпочковывается" от родителя по запросу пользователя. Не исключено, что данная технология заменит текущие механизмы связанных клонов в VMware View Composer.

За механизм шаринга общих страниц памяти будет отвечать уже существующая техника Transparent Page Sharing, которую отключат для обычных ВМ в следующих релизах, но она будет продолжать трудиться на благо VMFork.

Очевидно, что применений у такой технологии очень много - от мгновенного создания десктопов по требованию для продуктивной VDI-среды (не надо понапрасну загружать ресурсы "теплыми" десктопами) до тестовых окружений, где разработчик или тестировщик могут мгновенно создать себе рабочее окружение для различных проверок и тестов.

Кстати, помните мы писали про решение CloudVolumes, которое позволяет распространять виртуализованные приложения VMware ThinApp в виде дисков VMDK, которые можно подцепить к виртуальным машинам, предоставляя тем самым ее пользователям доступ к данному приложению?

Так вот если объединить Project Fargo (VM Fork) и CloudVolumes, то получится решение по почти мгновенному развертыванию рабочей среды пользователя со всеми необходимыми приложениями. Это решение внутри VMware называется Project Meteor.

Все эти штуки - VMFork и Project Meteor мы, возможно, увидим в обновленной версии платформы виртуализации VMware vSphere 6.0, которая выйдет в следующем году.

Четыре с половиной года назад мы писали про то, что у технологии Transparent Page Sharing (TPS), которая по-умолчанию используется в VMware vSphere, нет будущего. Напомним, что TPS - это механизм поиска и удаления дубликатов страниц памяти в целях экономии физического пространства RAM (вместо самой дублирующейся страницы хранится ссылка на нее).

Технолония потеряла актуальность, когда вовсю стали применяться большие страницы памяти (Large Memory Pages), для которых размер страницы равен 2 МБ, а значит вероятность появления двух полностью одинаковых страниц очень низка.

Ну вот и пришло время эту технологию отключать. На днях компания VMware выпустила статью базы знаний "Security considerations and disallowing inter-Virtual Machine Transparent Page Sharing", в которой заявляется о том, что в будущих релизах платформы виртуализации VMware vSphere функции TPS будут по умолчанию отключены (хотя и доступны).

Это во многом связано с тем, что TPS (помимо негативного влияния на производительность хоста) - это еще и потенциальный источник проблем, связанных с неавторизованным доступом к данным оперативной памяти. Эти моменты основаны на аналитическом исследовании, выводы из которого опубликованы в статье базы знаний "Additional Transparent Page Sharing management capabilities in ESXi 5.5 patch October 16, 2014 and ESXi 5.1 and 5.0 patches in Q4, 2014 (2091682)".

Вот когда TPS будет отключен в VMware vSphere:

• ESXi 5.5 Update release – Q1 2015
• ESXi 5.1 Update release – Q4 2014
• ESXi 5.0 Update release – Q1 2015
• VMware ESX 6.x и более поздние версии

Более подробно о проблемах с TPS написано вот в этой статье на блогах VMware.

Если же вы хотите отключить этот механизм уже прямо сейчас, то нужно сделать следующее:

1. Залогиниться на ESX\ESXi или vCenter Server через vSphere Client.
2. Выбрать нужный хост и зайти на вкладку Configuration, затем перейти в Advanced Settings в секции Software.
3. Выбираем раздел Mem и в нем устанавливаем значение параметра Mem.ShareScanGHz в 0.

После патча и обновлений ESXi механизм TPS можно будет включить следующим образом (Advanced Settings в секции Software):

• Параметр Mem.ShareForceSalting (включение TPS на уровне всего хоста ESXi). Если значение стоит 0 - то значит TPS по-прежнему работает на хосте, если 1 - механизм отключен.
• Параметр sched.mem.pshare.salt (ставится на уровне ВМ) позволяет включать/отключать TPS для отдельных виртуальных машин (например, старые Windows или линуксы - для них можно было бы включить). Когда параметр ShareForceSalting установлен в значение 1, то для нуждающихся в TPS машин в их Advanced Configuration нужно установить одинаковые значения "соли". Без этого TPS не работает - соответственно, он отключен.

На проходящей сейчас в Барселоне конференции VMware VMworld Europe 2014 компания VMware сделала немало интересных анонсов. Один из них - анонс VMware vRealize Operation Management Suite 6.0 (vROPS), который объединяет в себе несколько продуктов, которые теперь будут известны под новыми именами.

Напомним, что о vRealize Suite мы уже писали вот тут, когда проходил VMworld 2014 в штатах. Суть ренейминга продуктов заключается в следующем:

А точнее:

• vRealize Suite - это комплект продуктов vCAC + vCenter Operations Suite + Log Insight + ITBM
• vRealize Operations (он же бывший vCenter Oerations Suite)
• vRealize Operations Manager (он же vCenter Operations)
  vRealize Operartions Insight (аддон VSOM, продукт vRealize Operations + Log Insight).

Также будут добавлены еще два новых продукта:

• vRealize CodeStream 1.0 - доставка кода приложений в продакшен.
• vRealize Air Compliance (Beta) - возможность проверки виртуальной производственной среды на соответствие нормативным документам и отраслевым стандартам (например, VMware vSphere Security Hardening).

По-сути, комплект продуктов vRealize Suite 6.0 представляет собой платформу для управления гибридным облаком на решениях VMware (а именно, частная инфраструктура VMware vSphere + публичное облако VMware vCloud Air).

С помощью vRealize предполагается управлять не только гибридным облаком от VMware, но также и другими лидирующими на рынке публичными облаками (например, виртуальными машинами в облаке Amazon EC2).

Кроме того, с помощью компонентов vRealize предполагается также управлять и физическими системами:

Новые возможности и улучшения комплекта vROPS 6.0:

• Улучшены возможности развертывания отдельной установки на площадке.
• Поддержка работы компонентов в режиме кластера - общие данные и интерфейс пользователя.
• Режим Resiliency (так называемый RAID из приложений).
• Умные алерты (smart alerts) с возможностью получить детальную информацию о проблемах, которые могут произойти.
• Кастомизабельные дэшборды и отчеты (можно править их посредством drug and drop).
• Улучшения модели расчета необходимых дисковых емкостей для растущей инфраструктуры, с возможностями по сохранению данных расчетов и выполнения моделирования по схеме "что-если?".
• Публичный API, доступный партнерам VMware.
• Возможность интеграции management packs, которые доступны на VMware Solution Exchange (всего около 40-50 штук для разных приложений).

Решения vROPS развертываются в виде виртуальных модулей, между которыми создается кластер. Узлы в нем называются слайсами (slices):

Есть специальная консоль, где можно наблюдать за жизнедеятельностью узлов:

При первом развертывании решений пакета вам предлагается ответить на несколько вопросов мастера, который развернет компоненты решения в зависимости от вашего выбора:

На дэшбордах можно увидеть основные проблемы жизнедеятельности датацентра, потенциальные риски и какие-то метрики эффективности:

При клике на алерт вам предлагают вариант решения:

Также можно использовать заранее подготовленные сценарии для устранения проблем определенного типа.

Если проблему сходу не решить, то можно использовать решение VMware Log Insight для проведения более глубокого анализа (то есть, "ковыряния в логах"):

Если проблема повторится, то вы уже будете видеть ее описание и решите ее мгновенно.

Каждое представление может быть преобразовано в отчет:

Можно также создавать кастомные отчеты:

VMware vRealize Suite 6.0 доступен в двух изданиях:

• Advanced ($5750 за CPU сервера)
• Enterprise ($9950 за CPU)

VMware vRealize Operations Insight также лицензируется отдельно по процессорам (цена начинается от $2000 за CPU). Все указанные цены - американские, у нас будет значительно дороже.

Доступность и стоимость VMware vRealize Air Automation пока еще не раскрывается, но на бета-тест можно подписаться вот тут: http://vrealizeair.vmware.com.

Часто пользователям требуется информация о том, какому номеру билда соответствует версия продукта от VMware (такое бывает нужно, например, для VMware vSphere / ESXi, vCenter, vCenter Server Appliance). К тому же, иногда бывает полезно узнать, когда вышла та или иная версия продукта.

Поэтому мы взяли из этого поста информацию о продуках, датах релиза и номерах версий, чтобы можно было всегда обращаться к этому посту у нас.

Converter Standalone / Enterprise

Нажимайте читать далее.

Некоторое время назад мы писали о средстве преобразования виртуальных машин между платформами StarWind V2V Converter, которое иногда помогает в случае необходимости конвертации виртуальных дисков VMDK->VHD и обратно.

Так вот на днях компания StarWind обновила свой V2V Converter, который обзавелся некоторыми новыми возможностями. Теперь вот что с ним можно делать:

• Свободно конвертировать диски виртуальных машин между форматами VMDK, VHD/VHDX и форматом StarWind IMG.
• При клонировании исходный диск сохраняется - и вы можете использовать его как бэкап на случай проблем с целевым виртуальным диском.
• При конвертировании в формат VHDX происходит автоматическая активация режима Windows Repair Mode, что позволяет подхватить изменения в виртуальном аппаратном обеспечении после конверсии.

Конверсия между форматами VMDK, IMG и VHD/VHDX возможна в любую сторону:

Продукт V2V Converter может понадобиться компаниям, которые используют обе платформы виртуализации от VMware и Microsoft одновременно, а также в специфических случаях. Например, когда администратор филиала сделал виртуальную машину с нужными сервисами на платформе Hyper-V, а вам ее потом нужно интегрировать в инфраструктуру VMware vSphere центрального датацентра.

Скачать последнюю версию StarWind V2V Converter можно по этой ссылке.

Мы довольно часто пишем про продукт номер 1 для защиты виртуальных инфраструктур VMware и Microsoft - vGate R2. Напомним, что недавно мы рассказали о новых возможностях решения vGate R2 для Hyper-V, которое вышло несколько месяцев назад, но уже обладает очень мощным функционалом.

Решение vGate R2 предназначено для защиты виртуальных инфраструктур средствами политик, а также от несанкционированного доступа к элементам инфраструктуры, таким как виртуальные машины, хранилища и сети. Продукт имеет все необходимые сертификаты ФСТЭК и позволяет пройти проверку на обеспечение защиты персональных данных в контролирующих органах.

В этой заметке мы хотели рассказать про калькулятор стоимости vGate R2. От таких вендоров, как VMware или Citrix не дождешься конечной цены продукта для пользователя, а вот компания Код Безопасности дает честный расчет стоимости своего решения, да еще и в рублях (что особенно приятно с учетом текущей ситуации с курсами валют).

Итак, заходим в калькулятор, вводим такие параметры как:

• Издание продукта (обычный vGate или vGate-S для защиты гостайны, об отличиях мы писали тут)
• Количество процессоров (сокетов) защищаемых хост-серверов
• Наличие резервного сервера vGate
• Вид годового технического обслуживания

После этого получаем расчет в рублях (кликните на картинку для увеличения):

По этим ценам можно и заказать продукт vGate R2 у поставщика. Не правда ли удобно и честно?

Те из вас, кто много всего устанавливает в своей тестовой лаборатории или продакшен-среде VMware vSphere, наверное рано или поздно сталкиваются с тем, что vSphere Web Client очень медленно грузится (иногда по 2-3 минуты) или тормозит при работе в нем.

Одна из возможных причин тормозов - наличие установленных плагинов, которые может быть вам уже и не нужны, а отъедают системные ресурсы.

Поэтому иногда целесообразно удалить их. Идем в Managed Object Browser (MOB) на сервере vCenter, для чего переходим в браузере по такой ссылке:

http://<vcenter_name_or_IP>/mob

Далее после аутентификации переходим в раздел "content" (здесь и далее необходимые ссылки подсвечены желтым):

Затем переходим в раздел ExtensionManager:

Там нам нужно найти соответствующий плагин для удаления. Вот таблица всех плагинов VMware, которые могут быть подцеплены к Web Client:

Например, нам надо из vSphere Client удалить плагин vSphere Data Protection, находим его (записываем - все, что в квадратных скобках без кавычек) и проваливаемся дальше:

Вызываем для него метод UnregisterExtension:

В качестве значения при вызове метода указываем имя плагина, например, "com.vmware.vdp":

После успешного вызова метода он должен возвратить результат "void":

Таким вот нехитрым способом можно удалить все лишние плагины с сервера, где установлен vSphere Web Client, после чего последний станет значительно быстрее запускаться.

Идея и картинки взяты здесь.

Некоторое время назад мы писали о том, что компания Код Безопасности, известная многим по решению vGate R2 для защиты инфраструктуры VMware vSphere, выпустила версию vGate R2 для инфраструктур Microsoft Hyper-V. Это решение позволяет проводить защищенную аутентификацию администраторов, разграничивать доступ к различным объектам инфраструктуры и проводить аудит событий безопасности.

Новая архитектура сервисов управления VMware vCenter в VMware vSphere 6.

Некоторое время назад мы писали о новых возможностях платформы виртуализации VMware vSphere 6, о которых было подробно рассказано на прошедшей конференции VMworld 2014. Одним из нововведений новой версии станет новая архитектура сервисов управления VMware vCenter.

Надо начать с того, что "толстый" десктопный клиент vSphere Client в vSphere 6 по-прежнему останется доступен для управления виртуальными машинами через vCenter. Причины просты - компании VMware так и не удается довести до ума Web Client - он все еще притормаживает и не настолько быстро обновляет статус объектов, как это делает обычный vSphere Client. Однако все новые возможности будут появляться только в vSphere Web Client.

С точки зрения самого vCenter появляется новый сервис Platform Services Controller (PSC), который заменяет существующие сервисы Single Sign-On (напомним, что они уже были переписаны в версии SSO 5.5). Если ранее SSO был частью vSphere и обновлялся только вместе с платформой, то теперь PSC может быть обновлен отдельно (например, если появились новые источники аутентификации или были исправлены ошибки), что очень удобно.

На картинке ниже Infrastructure Controller (это так сейчас в бете называется Platform Services Controller) может быть выделен для каждого сервиса vCenter, но также и несколько сервисов vCenter могут использовать один PSC.

В обоих случаях сохраняются функции синхронизации данных между контроллерами и механика их отказоустойчивости.

Помимо стандартных функций аутентификации SSO, компонент PSC возьмет на себя управление лицензиями, а также хранение сертификатов.

Когда у вас до 8 серверов vCenter в рамках одной географической площадки, то можно использовать один PSC (который устанавливается на том же хосте, где и один из серверов vCenter). Ну а если у вас несколько датацентров, то для каждого разумнее использовать свой PSC, к которому подключаются не только сервисы vCenter, но и другие компоненты виртуальной инфраструктуры, например, продукт для управления облачной инфраструктурой VMware vCAC или средства автоматизации vRealize Orchestrator (бывший vCenter Orchestrator):

Шестую версию vCenter уже настоятельно рекомендуют устанавливать в виртуальной машине, так как только тогда можно будет воспользоваться преимуществами технологий отказоустойчивости и непрерывной доступности VMware HA и VMware Fault Tolerance. Ранее был продукт и для физических серверов - vCenter Heartbeat, но его сняли с производства.

Настало время объединить все сервисы управления виртуальной средой (vCenter, серверы vCAC, vCenter Log Insight, vCenter Orchestrator, vCenter Operations Manager и т.п.) в виде блоков в виртуальных машинах:

Также весьма существенно будет доработан виртуальный модуль vCenter Server Appliance (vCSA). Теперь он будет поддерживать до 1 000 серверов ESXi под своим управлением, 10 000 включенных виртуальных машин, 64 хоста ESXi на кластер HA/DRS, 6 000 ВМ в кластере, а также 10 серверов vCenter в режиме Linked Mode.

Как многие из вас знают, ранее режим Linked Mode не поддерживался со стороны vCSA, так как для этого режима использовалась модель Active Directory Application Mode (ADAM), не поддерживаемая в Linux. Теперь для Linked Mode используется собственная аутентификация, поэтому объединение нескольких машин vCSA в единую мета-сущность теперь вполне возможно.

Как Windows-версия, так и vCSA будут использовать встроенную БД vPostgres, а в качестве внешних БД стандартно будут поддерживаться Microsoft SQL Server и Oracle.

Ну и, помимо всего прочего, сейчас ходят слухи о выпуске вместе с VMware vSphere 6 утилиты для миграции с Windows-версии vCenter на vCSA. Эта штука для многих пользователей будет очень кстати.

ИТ-ГРАД запускает новую облачную площадку в дата-центре SDN. Перед переводом площадки в промышленную эксплуатацию мы должны убедиться в том, что все ее компоненты работают как задумывалось, а дублирование и обработка аппаратных сбоев происходит в штатном режиме. Для проверки работоспособности новой облачной площадки был разработан план тестирования, с которым вам и предлагаем ознакомиться.

Немного о наполнении новой площадки:

На первом этапе в новый ЦОД была установлена система хранения данных NetApp FAS8040 (мы как золотой партнер компании NetApp – остаемся верны вендору), система пока имеет 2 контроллера FAS8040, которые собраны в кластер через дублируемые 10Gbit/s коммутаторы (Cluster Interconnects) и позволяют наращивать кластер СХД до 24 контроллеров. Контроллеры СХД в свою очередь подключены к сети ядру сети по 10Gbit/s оптическим линкам сформированое двумя коммутаторами Cisco Nexus 5548UP с поддержкой L3.

Серверы гипервизоров VMware vSphere ESXi (Dell r620/r820) подключаются к сети по двум интерфейсам 10Gbit/s, используя конвергентную среду передачи данных (для работы с дисковым массивом и сетью передачи данных). Пул ESXi серверов образует кластер с поддержкой VMware vSphere High Availability (HA). Менеджмент интерфейсы серверов iDRAC и контроллеров СХД собираются на отдельном выделенном коммутаторе Cisco.

Когда базовая настройка инфраструктуры фактически была завершена настало время остановиться и оглядеться назад: ничего не забыли? все ли работает? надежно?

Задел на успех в лице опытных инженеров мы уже имеем, но чтобы «фундамент» оставался крепким, необходимо, конечно же, правильно провести испытания на стрессоустойчивость инфраструктуры. Успешное окончание тестов будет свидетельствовать о завершении первого этапа и сдачи приемо-сдаточных испытаний (ПСИ) новой облачной площадки.

Итак, озвучу «исходные данные» и «план тестирования». А внимательные читатели, которым не чужда судьба ИТ-ГРАДа, могут внести предложения/рекомендации/пожелания возможных моментов, которые мы могли не предусмотреть. С радостью их выслушаем.

«Исходные данные»:

• FAS8040 dual controller под управлением Data ONTAP Release 8.2.1 Cluster-Mode
• Дисковые полки NetApp DS2246 (24 x 900GB SAS) – 5 шт.
• NetApp FlashCache 512Gb – 2шт.
• NetApp Clustered Ontap CN1610 Interconnect Switch – 2 шт.
• Коммутаторы ядра унифицированной сети Cisco Nexus 5548 – 2 шт.
• Пограничный роутер Juniper MX80 (пока один, второй ещё не приехал).
• Управляемый коммутатор Cisco 2960.
• Серверы Dell PowerEdge R620/R810 with VMware vSphere ESXi 5.5.

Схема подключения выглядит следующим образом:

Нарочно не стал рисовать менеджмент свитч и Juniper MX80, т.к. связность интернет будем тестировать после резервирования канала, не хватает ещё одного Juniper MX80 (ждем к концу месяца).

Итак, условно наши «краш-тесты» можно поделить на 3 вида:

• Тестирование дискового массива FAS8040;
• Тестирование сетевой инфраструктуры;
• Тестирование виртуальной инфраструктуры.

При этом тестирование сетевой инфраструктуры в нашем случае выполняется в укороченном варианте по причинам, которые я указывал выше.

Перед тестами планируется ещё раз сделать бэкапы конфигураций сетевого оборудования и массива, а также проанализировать результаты дискового массива с помощью Config Advisor.

Теперь давайте расскажу подробнее о плане тестирования.

I. Удаленное тестирование

1. Поочередное выключение контроллеров FAS8040.
   Ожидаемый результат: автоматический takeover на рабочую ноду, все ресурсы VSM должны быть доступны на ESXi, доступ к датасторам не должен пропадать.
2. Поочередное отключение всех Cluster Link одной ноды.
   Ожидаемый результат: автоматический takeover на рабочую ноду, либо перемещение/переключение VSM на доступные сетевые порты на второй ноде, все ресурсы VSM должны быть доступны на ESXi, доступ к датасторам не должен пропадать.
3. Отключение всех Inter Switch Link между свичами CN1610.
   Ожидаемый результат: предполагаем, что кластерные ноды будут доступны друг для друга через cluster links одного из Cluster Interconnect (в связи с перекрестным соединением NetApp — Cluster Interconnect).
4. Перезагрузка одного из Nexus.
   Ожидаемый результат: один из портов на нодах должен оставаться доступным, на IFGRP интерфейсах на каждой ноде должен оставаться доступен один из 10 GbE интерфейсов, все ресурсы VSM должны быть доступны на ESXi, доступ к датасторам не должен пропадать.
5. Поочередное гашение одного из vPC (vPC-1 или vPC-2) на Nexus.
   Ожидаемый результат: перемещение/переключение VSM на доступные сетевые порты на второй ноде, все ресурсы VSM должны быть доступны на ESXi, доступ к датасторам не должен пропадать.
6. Поочередное отключение Inter Switch Link между коммутаторами Cisco Nexus 5548.
   Ожидаемый результат: Port Channel активен на одном линке, нет потери связности между коммутаторами.
7. Поочередное жесткое отключение ESXi.
   Ожидаемый результат: отработка HA, автоматический запуск ВМ на соседнем хосте.
8. Слежение за отработкой мониторинга.
   Ожидаемый результат: получение нотификаций от оборудования и виртуальной инфраструктуры о появившихся проблемах.

II. Непосредственно на стороне оборудования

1. Отключение кабелей питания (все единицы оборудования).
   Ожидаемый результат: оборудование работает на втором блоке питания, нет проблем с переключением между блоками.
   Замечание: Менеджмент свитч Cisco не имеет резервирования питания.
2. Поочередное отключение сетевых линков от ESXi (Dell r620/r810).
   Ожидаемый результат: ESXi доступен по второму линку.

Ну вот и все, жду ваших мнений.

Ссылка на статью в блоге ИТ-ГРАД.

Компания StarWind, поставщик ПО номер 1 для создания отказоустойчивых кластеров хранилищ в инфраструктурах VMware vSphere и Microsoft Hyper-V (о возможностях продукта - тут), в ближайшее время проведет два интересных вебинара:

• 30 сентября - VEEAM Backup & Replication vs. StarWind Virtual SAN:
  Business Continuity and Disaster Recovery Run Entirely by RTO / RPO Numbers

На совместном с компанией Veeam вебинаре Макс Коломейцев от имени StarWind расскажет, как с помощью продуктов StarWind Virtual SAN для отказоустойчивой конфигурации хранилищ и Veeam Backup and Replication для резервного копирования достичь высоких показателей RTO и RPO в вашей виртуальной инфраструктуре. Вебинар для тех, кто давно хочет понять, как эти два продукта уживаются вместе, и какой позитивный эффект они дают.

Бесплатный вебинар пройдет 30 сентября в 22-00 по московскому времени. Как раз после ужина. Регистрируйтесь!

• 1 октября - StarWind Virtual SAN break-out session: Hyper-converged storage for Hyper-V clusters

Вебинар пройдет 1 октября также в 22-00 по московскому времени.

На этом вебинаре Макс Коломейцев расскажет про развертывание и настройку кластеров серверов и хранилищ на базе платформы Microsoft Hyper-V и продукта StarWind Virtual SAN (а также про отсутствие необходимости приобретать дополнительное железо и ПО). Напомню, что Макс является продакт-менеджером Virtual SAN, а значит знает о нем абсолютно все. Регистрируйтесь и спрашивайте!

На днях компания VMware выпустила очень полезный для администраторов виртуальных инфраструктур документ VMware Horizon 6 Reference Architecture на 53 страницах, в котором приведена типовая конфигурация VDI-среды на 2000 виртуальных ПК, расширяемая до 10 000 пользователей в случае необходимости.

В документе рассмотрена архитектура на базе серверной инфраструктуры Supermicro и хранилища EMC VNX 5500. На данной конфигурации удалось добиться следующих результатов:

Конфигурация программно-аппаратного комплекса:

• Хосты ESXi с процессорами 2.1 ГГц Intel E5-2658 или 2.9 ГГц E5-2690
• 128 ГБ RAM на один хост ESXi
• Хранилище для виртуальных ПК EMC VNX5500 на базе протокола NFS (20 ТБ)
• Сетевое оборудование 10 Gigabit Ethernet (GbE)
• Виртуальные машины Windows 7 с одним vCPU и 1GB vRAM (типовая "легкая" пользовательская нагрузка)
• Виртуальные машины с ролью Microsoft Remote Desktop Session Host (RDSH) с четырьмя vCPU и 24 ГБ RAM
• ПО VMware Horizon 6 на платформе VMware vSphere 5.5

А вот собственно и сама аппаратная конфигурация описанной в документе архитектуры:

В качестве составляющих программной среды используются все компоненты решения VMware Horizon 6 (View, Mirage 5.0 и Workspace Portal 2.0), работающие на платформе VMware vSphere 5.5.

Документ очень насыщен техническими деталями и рекомендуется к прочтению всем тем, кто планирует масштабное развертывание инфраструктуры виртуальных и физических ПК на базе семейства решений VMware Horizon 6.

На сайте проекта VMware Labs (напомним, что за его обновлениями можно следить у нас вот тут) появился интересный плагин для VMware vSphere Web Client - PowerActions. Он позволяет хранить и исполнять сценарии PowerCLI прямо из веб-клиента, что очень удобно, когда администратор выполняет повседневные задачи по управлению виртуальной инфраструктурой, где некоторые операции автоматизированы средствами PowerShell.

Кроме того, PowerActions предоставляет высокую степень интеграции с vSphere Web Client - вы можете, например, открыть контекстное меню для объекта (к примеру, виртуальная машина или кластер) и выполнить скрипт PowerCLI для него.

Кроме всего прочего, PowerActions - это отличный способ расшарить ваши скрипты другим администраторам виртуальной инфраструктуры VMware vSphere, которые могут нуждаться в ваших наработках.

Вот тут в блоге компании VMware очень детально расписано как установить и пользоваться плагином PowerActions for vSphere Web Client. Скачать его можно по этой ссылке.

Не так давно мы писали о новых возможностях лидирующей на рынке платформы виртуализации VMware vSphere 6, которая на данный момент доступна в публичной бета-версии.

Одной из новых возможностей был заявлен механизм vSphere APIs for IO Filtering (VAIO - как ноутбуки от Sony), который позволяет получать прямой доступ к потоку ввода-вывода (I/O Stream) гостевой ОС виртуальной машины. Несмотря на то, что об этой штуке писали достаточно мало, механизм VAIO в будущем будет способствовать созданию множества партнерских продуктов для решения самых разнообразных задач. VAIO основан на механике Storage Policy Based Management (SPBM), которая предназначения для управления хранением виртуальных машин.

Техническая реализация данного механизмв подразумевает использование драйвера VAIO (filter driver), который устанавливается на хосте VMware ESXi как пакет VIB и не требует установки никакого специального ПО в гостевой ОС виртуальной машины. Работает он на уровне VMDK-диска отдельной ВМ и позволяет не только получать данные из потока ввода-вывода, но и изменять его при течении данных в ту или другую сторону.

Это открывает возможности для применения VMware VAIO при решении следующих типов задач:

• Encryption – стороннее ПО за счет использования механизма VAIO может на лету шифровать и расшифровывать поток данных от виртуальной машины. Таким образом на хранилище будут помещаться уже шифрованные данные. Гранулярность работы VAIO позволяет обслуживать данные идущие даже не от всей виртуальной машины, а только от одного приложения.
• De-duplication - этот механизм уже использует решение VMware Virtual SAN. В реальном времени можно дедуплицировать данные, проходящие через драйвер и в таком виде уже класть на хранилище в целях экономии дискового пространства. Теперь это станет доступно и партнерам VMware.
• Tiering - данные различной степени важности, критичности или классифицированные по другим критериям теперь можно класть на хранилища с разными характеристиками производительности и доступности (ярусы). Механизм VAIO тут поможет проанализировать характер данных и определить конечное их место назначения.
• Analytics - теперь можно анализировать непосредственно поток данных от конкретной виртуальной машины и на основе этого строить множество различных решений, включая решения по кэшированию (например, такой продукт как CahceBox можно будет напрямую подключить к гипервизору). Затем можно, например, искать в трафике данные определенных приложений, либо, например, использовать механизм write-back кэширования.

На первом этапе запуска технологии VAIO компания VMware решила остановиться на двух путях ее имплементации:

1. Возможности кэширования данных на SSD-накопителях (write-back кэширование для операций записи). Дизайн-документ для API тут делала компания SanDisk, которая первой будет использовать VAIO в своих продуктах. Вот их презентация:

А вот технология write-back кэширования на стороне сервера с использованием механизма VAIO:

2. Возможности высокопроизводительной репликации. Реализация данного аспекта VAIO позволит получать прямой доступ к потоку ввода-вывода и сразу же передавать его на другой хост, не прибегая к дополнительным механизмам, которые сегодня используются для реализации техник репликации. На данный момент заявлено, что такой тип репликации будет поддерживать ПО EMC RecoverPoint, команда которого принимала участие в разработке техники VAIO.

Однако несмотря на все плюсы технологии vSphere APIs for IO Filtering, в ней есть и негативные стороны:

• Во-первых, это вопрос надежности. Так как между виртуальной машиной и хранилищем есть дополнительное звено, которое может рухнуть, понижается и совокупная надежность платформы виртуализации.
• Во-вторых, это вопрос производительности. Прослушка трафика посредством VAIO неизбежно создает нагрузку на аппаратные ресурсы хоста ESXi.
• В-третьих, это вопрос безопасности. Представим, что я написал софт, который прозрачно шифрует и расшифровывает трафик отдельной виртуальной машины на хосте ESXi, после чего внедрил его в инфраструктуру предприятия, где все это произошло незаметно для пользователей и администраторов. Затем я просто убираю это ПО из гипервизора (например, при увольнении), после чего данные на хранилищах превращаются в тыкву, а компания сталкивается с серьезной проблемой.

В целом же, подход VMware в данном вопросе очень радует - она открывает партнерам возможности разработки собственных продуктов для решения задач пользователей, а значит предоставляет и неплохую возможность заработать.

Первые реализации механизма vSphere APIs for IO Filtering мы должны увидеть уже в первой половине 2015 года, когда выйдет обновленная версия платформы VMware vSphere 6.